Currently, businesses or industrial or commercial companies use, as a quasi-necessity, the interchange of data and information supported by this data, via the IP network.
More widely, these businesses or companies are multi-establishment organizations, with one or more establishments normally being associated with at least one computer site, or web site, these sites being interlinked via an IP network. These businesses or companies are therefore also multisite entities, forming one and the same original organization.
As a general rule, the IP multicast information broadcasting method is used for broadcasting information to each of the abovementioned sites.
There are in fact three types of multicast broadcast defined in the RFC 2365 standard (administratively scoped IP multicast):                broadcasts private to the site, also designated broadcasts local to the site, performed only to terminals affiliated to and managed by the original site, via an original home network, these local broadcasts never being transmitted from one site to another even though the latter are affiliated to the same original organization;        broadcasts private to the original organization, typically the business, also called broadcasts local to the organization, performed only to terminals affiliated to the original organization, these broadcasts local to the organization never being transmitted to an organization external to the original organization;        global broadcasts, these broadcasts being able to be broadcast to all the INTERNET and therefore accessible from any local IP network or access point connected to the latter.        
A review of the multicast broadcasting technique will first of all be given in conjunction with FIGS. 1a and 1b. 
In the case of the multicast broadcasting technique, with reference to FIGS. 1a and 1b, a receiver, R6, wishing to have access or subscribe to a multicast broadcast sends an access request to its access router RO6, according to the IGMP method (RFC 2236). The access router RO6 uses a multicast routing protocol, the PIM-SM method (RFC 2117) for example, to relay this request to the point of the network (switching point or router) that is already receiving this broadcast, where appropriate, directly to the access router RO0 of the broadcasting source, as represented in FIG. 1a. The routing of the abovementioned request is represented by solid line arrows in FIG. 1a. 
Each router belonging on the route keeps in memory the software interface, routing data and addresses, via which it has received a request to subscribe to a predetermined broadcast. When the router concerned receives the IP data packets relating to this broadcast, it transmits them to its neighboring router by reverse path, using the stored software interface.
Thus, the IP data packets corresponding to this broadcast reach the requesting receiver R6 by reverse path. The reverse path is represented by broken line arrows in FIG. 1a. 
When a new receiver, the receiver R1 for example, as represented in FIG. 1a, wants to access this same broadcast, it sends its access request to its access router RO4. The latter transmits this request until it reaches a router executing the requested broadcast, in this case the router RO2 in FIG. 1a. The path of this request is represented by mixed line arrows in FIG. 1a. 
The most forward router, in the direction of the broadcast, reached by this request, which is already receiving the data and information of the broadcast requested by the receiver R1, stops returning this request to the broadcasting source, server SD, duplicates the IP data packets to transmit the latter also to the receiver R1 using the stored software interface, by reverse path. The path of the full broadcast is represented by broken line arrows in FIG. 1a, the reverse path RO2-RO3-RO4-R1 being represented by a double broken line arrow in FIG. 1a, although belonging to the same multicast broadcast as that requested by the receiver R6. The same applies for any receiver R2 to R5 likely to request this same broadcast.
Consequently, with the IP multicast broadcast technique, it will be understood that the server SD sends the data supporting the information that makes up the broadcast only once. This data is duplicated by the routers of the network dynamically, to reach the authorized receivers that have made the request. The set of paths or routes followed by the IP data packets of the broadcast, from the server SD to these authorized receivers, forms a multicast information broadcasting tree, the root of which is the broadcasting source, server SD or root router RO0, the various routes forming the branches and the end receivers forming the leaves. It should be understood, in particular, that, following the access request from the receivers R6 and R1, in the case of an access request from the receiver R4, the branch RO2-RO9 and the receiving leaf R4 are added whereas in the case of an access request from the receiver R2, only the receiving leaf R2 is added.
As for the IP multicast addressing, the multicast broadcasting technique introduces the concept of multicast broadcast. An IP data packet that is part of a multicast broadcast has a destination IP address, called multicast address. All the data packets supporting information belonging to the same broadcast have the same destination multicast address. Whereas a unicast IP address can be used to identify just one receiving machine or workstation, a multicast IP address is used to identify a set or group of machines, the set of machines authorized to access this broadcast. A multicast address is therefore always a destination address and would be meaningless as a source address. To this end, a part of the IP address codes is reserved for assigning multicast addresses.
Specifically, the standard RFC 2365 (Administratively Scoped IP Multicast) defines a way of assigning certain multicast addresses an administrative limit to the broadcast that these addresses represent.
Depending on the value of the multicast address assigned to a broadcast, this broadcast is consequently intended, as mentioned previously, to be limited:                to a site (site-local scope);        to an organization (organization-local scope);        to all the Internet (global scope).        
The possibilities offered by the abovementioned multicast broadcast concept for broadcasting data to the different sites of a business or multisite entity appear currently to be significantly limited.
If, with reference to FIG. 1b, we consider a multisite entity located on four separate sites, site 1, site 2, site 3 and site 4, site 1 including, for example, a multicast broadcast server SD, such a broadcast, according to a “site-local scope” mode, is local to site 1. Consequently, the IP data packets supporting the information of this broadcast are not sent outside of the site. These data packets therefore do not cross the interconnecting network and cannot be received by the users of other sites, site 2, site 3 and site 4.
The abovementioned different broadcast types have a very significant impact on the access restrictions affecting any roaming terminal affiliated to an original organization, according to the location of the network, local IP network and/or INTERNET, to which the latter is connected.
Discriminating the location of the connection of any roaming terminal affiliated to an original organization, such as a multisite business, is therefore crucial, in order to implement a specific selective broadcasting method towards a roaming terminal, such a broadcast needing, in particular, to be totally selective, of the point-to-point broadcast type, when this roaming terminal is connected to a network outside its original organization, and, more often than not, when this same roaming terminal, although connected to a site affiliated to its original organization, is not connected to its original site.
These situations are represented in FIG. 1c, for a roaming terminal T network-connected to its original site S1, to sites S2 and S3 separate from the original site S1 but affiliated to the original organization O0 and to any site Sp affiliated to an organization Op separate from the original organization O0, the terminal being denoted T1, T2, T3 and Tp successively.
In the abovementioned situations, this roaming terminal can be reached only by the global broadcasts, or the global broadcasts and broadcasts local to the original site.
In practice, some IP network services use the concept of hierarchy of the IP network architecture. These services can limit their network scope to a link, a site, an organization, or even extend this scope to all of the INTERNET.
In these conditions, it is essential for a terminal that is on the move to be able to determine if it is connected to its original home network, to another site affiliated to its original organization or to another site external to the latter.
The location of this connection is in fact likely to modify the recognized capabilities of this terminal that is on the move to access the services of the IP network for which the access is restricted by the original organization of the latter, such as its business.
At the present time, the techniques for locating the connection of a roaming terminal that is on the move do not allow for this terminal to be informed of its location, in particular the location of its network connection either on its original site, or on another site separate from its original site but affiliated to its original organization, or even to a site affiliated to an organization separate from its original organization, or directly to the INTERNET.
Among the solutions currently available for locating terminals connected to the IP network, only partial solutions have been proposed.
The abovementioned partial solutions mainly consist of neighbor terminal discovery and error management protocols, such as are defined by the IETF (The Internet Engineering Task Force), by the documents:                RFC 2461 (Neighbour Discovery for IP Version 6) for the IP protocol, version 6, IPv6;        RFC 1256 (ICMP Router Discovery Messages) for the IP protocol, version 4, IPv4;                    by the dynamic IP address allocation protocols:                        RFC 2131 (Dynamic Host Configuration Protocol) for the IPv4 protocol;        RFC 3315 (Dynamic Host Configuration Protocol for IPv6, (DHCPv6));                    by the documents specifying the IP addressing architectures used by the abovementioned protocols:                        RFC 3513 (IPv6 Addressing Architecture) IPv6;        RFC 2365 (Administratively Scoped IP Multicast, RFC 1918 (Address Allocation for Private Internets), RFC 3232 (Assigned Numbers: RFC 1700 is replaced by an Online Database) for IPv4;                    by a document submitted to the IETF, which proposes a solution enabling a terminal of the IP network to distinguish the IPv6 prefix of its organization:                        draft-zill-ipv6wg-zone-prefixlen-oo.txt (Organization Zone Prefix Length Discovery).        
The solutions for terminal mobility management within IP networks are defined by the following IETF documents (www.ietf.org):                RFC 3344 (IP Mobility support for IPv4) for IPv4;        draft-ietf-mobileip-ipv6-20.txt for IPv6.        
The solutions for terminal mobility management within IP networks using an AAA “Authentication, Authorization, Accounting” infrastructure are defined by the following IETF documents (www.ietf.org):                Protocol Diameter: draft-ietf-aaa-diameter-17.txt        Application Mobile IPv4: draft-ietf-aaa-diameter-mobileip-13.txt;        Application Mobile IPv6: draft-le-aaa-diameter-mobileipv6-0.3.txt.        
The prior arts implementing the abovementioned solutions to support the movement of a roaming terminal present many drawbacks, due to unresolved operational problems.
All the fixed or roaming terminals connected to the same link, affiliated to the same original home network, forming a local area network for example, have an IP address with the same prefix, but different suffixes.
According to the IPv4 protocol, an IP address is encoded on 32 bits. The length of the prefix used to describe a network address is variable, from 1 to 30 bits. A part of the IPv4 addressing space, a set of addresses, is reserved for the “unicast” addresses, in accordance with the IETF document: RFC 3232. The term “unicast” denotes all of the “Unicast” and “Global Unicast” addresses.
According to the IPv6 protocol, an IP address is encoded on 128 bits. The length of the suffix of a “unicast” address is set at 64 bits, except for specific IPv6 addresses which begin with the word “000”, the use of which is highly regulated. A part of the IPv6 addressing space, a set of addresses, is reserved for the “unicast” addresses, in accordance with the IETF document: RFC 3513.
When a roaming terminal that is on the move connects to a receiving IP network that is separate from its original home network, there are currently three protocols that allow such a terminal to acquire an IP address enabling it to be integrated into the receiving IP network.
A first protocol, designated DHCP, for “Dynamic Host Configuration Protocol”, can be implemented within the framework of the abovementioned IPv4 and IPv6 protocols. It allows an IP terminal to ask an address server to allocate it an IP address from a pool, or set of addresses, that is specific to it for a period of time negotiated between the roaming terminal, the client, and the address server. On such an allocation, the requesting IP terminal also detects the prefix of the link to which it is connected. The series of IPv4 and IPv6 protocols defines a protocol called DHCPv4, or respectively DHCPv6, based on a dynamic allocation mechanism. The latter provides good flexibility in terms of configuration and makes it possible to allocate a client terminal an IP address and other configuration parameters in the network such as DNS (Domain Name System) address, as per documents RFC 1034 and 1035 published by the IETF, for routers, servers, gateways and the like.
A second protocol is an integral part of the “Mobile IP” protocols. In the context of the abovementioned IPv4 and IPv6 protocols, the corresponding versions of this second protocol are compatible with the use of the DHCP protocol, but use a different mode, better suited to the mobility of the roaming terminals within different IP networks. In both the abovementioned versions, this second protocol relies on the fact that the routers of the IP networks periodically transmit announcement messages, in particular in the IPv6 version, describing the prefix of the original home or receiving IP networks to which the fixed or roaming terminals are connected.
A roaming terminal on the move then uses these announcement messages to detect the prefix of the IP network to which it is connected, and uses it to self-generate and be assigned a unique, coherent “unicast” address. In the IPv4 version, however, the abovementioned periodic announcement messages can directly announce the complete “unicast” address which can be used by the roaming terminal on the move. This address is an address assigned to a router, managed by the latter, and can be used by a roaming terminal on the move when the procedures described in the Mobile IP protocol (for IPv4) are followed.
In the context of this second protocol, a fixed or roaming terminal has a fixed IP address, configured specifically in the terminal. This fixed IP address is part of the original home network of the terminal and constitutes a coherent address with the prefix of the original home link of the terminal, original home link and therefore network to which the roaming terminal is connected, when the latter is not on the move.
In the context of the “Mobile IP” protocols, a roaming terminal on the move always remains in contact with its original home network. To this end, there is provided, installed on the latter, a software agent called “Home Agent”, HA. When the roaming terminal on the move has acquired a new IP address that is different, and therefore unknown, to those that are part of its original home network, it then registers with its software agent HA by communicating to it the IP address that is newly acquired and that it will use from now on to communicate. Thus, the software agent HA still knows the IP address that it must use to enter into contact with the roaming terminal on the move.
A third protocol is also implemented mainly by the IP network access control protocols.
The access control protocols are used between the roaming terminal on the move and the first IP router of the receiving IP network, also called access router.
The access control protocol used between the access router and an access control server is normally the RADIUS protocol or a more recent development of the latter, the DIAMETER protocol.
Among the parameters conveyed by the DIAMETER and RADIUS protocols, there is one that specifies the IP address to be assigned to the roaming terminal on the move requesting access. This IP address is then transmitted to the terminal by the access control protocol.
In this type of architecture, an access control server affiliated to the original home network of the roaming terminal and implementing the DIAMETER protocol, this server also being designated AAAH, for “Authentication, Authorization, Accounting Home” server, is configured to handle the authentication and access authorization of the roaming terminal on the move.
Thus, the AAAH server is always notified when one of the terminals that it manages tries to connect to the IP network and can even, depending on the case, propose the IP address to be assigned to it.
The advantage of the DIAMETER protocol is that this protocol proposes a distributed architecture of access control servers, which makes it possible to control access to terminals via local area networks managed by separate organizations. When being allocated its new IP address, the roaming terminal on the move also detects the prefix of the link to which it is connected.
The drawbacks, due to inadequacies, of the abovementioned three current protocols can be summarized as follows.
The DHCP protocol, in addition to the address that it allows to be allocated to a terminal, is capable of providing other network configuration parameters to the latter. The main parameters are the network mask, the validity time granted to the new address, the default network gateway address, address of an access provider or an ISP (for “International Standard Profile”) via which the terminal will access the IP network, and the identifier of the client and the name of the server to be used.
However, it cannot compensate for the addressing-related problems inherent to the IPv4 protocol and its breakdown into sites and organizations.
In particular, the structure of the addresses and the terminal/router dialogs do not in any way allow the terminals to determine:                when an address is allocated to the IP terminal on the move;        whether it is connected to another link affiliated to its original site;        whether it is connected to a link from another site affiliated to its original organization;        whether it is connected to a link not affiliated to its organization;        whether the addresses cover a number of sites of one and the same business or a number of different businesses that can use the same network address prefixes.        
With the second protocol being an integral part of the “Mobile IP” protocols, when a terminal acquires a new IP address, this terminal can only determine the prefix of the subnetwork, such as a local area network, to which the new IP address that has been acquired belongs, and compare it to the prefix of its fixed address.
While it can make it possible to detect whether the roaming terminal is connected to its original link, on the negative side, it cannot in any way make it possible to determine whether the roaming terminal is connected:                to another link affiliated to its original site;        to a link affiliated to a site of its original organization;        to a link not affiliated to its organization.        
Furthermore, the second abovementioned protocol does not necessarily allow the roaming terminal to detect whether it is connected to its original home network. Such is in particular the case when there are overlapping addressing plans, that is, when a number of sites of one and the same business or several different businesses use the same network prefixes.
In these conditions, if the roaming terminal connects to an IP network using the same prefix as its original home network, in the absence of possible discrimination, this roaming terminal will, wrongly, believe it is connected to the latter.
Finally, when a roaming terminal on the move transmits IP data packets outside the site to which it is connected, a translation of the source address of the packets may be performed, for example in the case of overlapping addressing plans or if the sites of the organization are linked via the INTERNET. In these conditions, the roaming terminal on the move is therefore no longer accessible from the outside by its address acquired dynamically, but by its translated address. It will be remembered that, for any site to which a roaming terminal is connected, the interior denotes, in fact, all the networks and IP nodes that are interconnected and that are identifiable by all the private and public IP addresses of the organization to which the abovementioned any site belongs. The exterior denotes all the IP networks and nodes that cannot be identified from the abovementioned addresses.
In the case of the third protocol, the use of an access control protocol based on a DIAMETER type architecture results in the roaming terminal on the move having only a fixed identifier called NAI (Network Access Identifier), which makes it possible, among other things, to determine the AAAH server to be interrogated to request access. Furthermore, the roaming terminal does not know the IP address of the AAAH server affiliated to its original home network. Thus, when an address is assigned to the roaming terminal on the move, the latter cannot in any case determine if it is connected:                to another link affiliated to its original site;        to a link affiliated to another site of its original organization;        to a link not affiliated to its original organization.        
Besides the lapses relating to the inadequacies inherent in the location of the abovementioned protocols, the transmission of a multicast broadcast that is local to a site to another site, even if this site and this other site belong to one and the same original organization, is not possible.
Thus, when a roaming terminal on the move requests access to a broadcast identified by the multicast group address, it simply transmits an access request using the IGMP protocol, specifying the address for which it wants to receive the stream.
Such a method does not therefore make it possible, in any case, to take into account the location of the connection of the roaming terminal in order to transmit broadcasts local to the original site and/or organization, for which access is therefore restricted by this location.